Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ien/ien-201

Text File | 1988-12-01 | 18KB | 326 lines

Internet Experiment Note No. 201

                       INTERNET SHORT-TERM SERVICE GOALS
                                David D. Clark
                      MIT Laboratory for Computer Science
                   Computer Systems and Communications Group


1.  Introduction
  The  purpose of this document is to identify the milestones which must be met
in order to bring the current internet architecture to a stable  service  which
can  be  used while the next round of research development is undertaken.  This
document describes the functionality associated with the service to be offered,
and identifies the work to be done in order to achieve  that  function.    This
document  discusses  all  aspects  of the internet service, and is intended for
planning purposes within  the  internet  research  community.    More  detailed
documents  are available as RFC's that discuss the specifics of host conversion
from NCP to TCP.

  This document should be viewed in the larger context of the long-term project
planning which is now underway.  An assumption underlying this document is that
it is necessary to identify carefully a service which  we  will  provide  in  a
stable  form  at  this  time,  in  parallel  with  which  a  follow-on enhanced
capability will be designed and implemented in  selected  hosts  and  gateways.
This  current service should more or less mimic the quality of service provided
today on the ARPANET by the NCP protocol, in  terms  of  supported  application
protocols, reliability, responsiveness, etc.

2.  Service Milestones
  There  are  five  major  milestones in the achievement of the current service
offering.  Two of these relate to support of TCP on the  ARPANET.    The  other
three  relate  to  support of actual internet traffic.  These milestones are as
follows:

  1. First use of internet for service (now happening!)

  2. NCP quality support for first TCP-only host on ARPANET (July 1982)

  3. NCP quality service for internet (?)
                                       2

  4. Heavy load on internet (?)

  5. Last NCP host removed from ARPANET (January 1983)

  These   five  milestones  are  explained  and  elaborated  in  the  following
paragraphs.

3.  Milestone One:  Minimal Support for Internet Service
  Internet service is being used today, as part of the Fort Bragg packet  radio
demonstration  and  by the machines at COMSAT, which are not connected directly
to the ARPANET.  I would characterize the service currently available to  these
users  as  somewhat  less  than  minimal, in that it works only because certain
special case adjustments have been made to individual hosts.  There  are  three
important components to this milestone:

  a. Fragmentation  and  reassembly must be completely implemented through
     the internet.  It is repeatedly brought  home  that  the  failure  to
     implement   this   portion  of  the  protocol  causes  important  and
     substantial confusion.  At the last internet meeting, the failure  of
     the  TIU  to  support  reassembly once again prevented machines which
     sent jumbograms from being used.    There  is  no  justification  for
     continuing to sidestep this problem.

  b. Name  tables  on operational hosts must be upgraded so that they have
     both the structure and capacity to name  all  of  the  hosts  in  the
     internet.    In  the long term, we hope that it will not be necessary
     for every host to  maintain  a  complete  internet  table,  since  we
     postulate  the  existence of name servers to which an individual host
     can turn to convert a name to a number.  However,  name  servers  are
     not currently available, and the requirement for this name conversion
     is immediate.

  c. ICMP  must  be  supported.    Without ICMP, one cannot achieve even a
     minimal level of error recovery.

  These  subtasks  must  be  completed  quickly,  because  minimal  service  is
important  for  the  sites in Europe who are momentarily being removed from the
ARPANET. If the only requirement of the European community is user telnet, then
the name table problem on server hosts such  as  TOPS  20  can  be  momentarily
sidestepped, but the lack of fragmentation will prove totally unworkable, as it
already has.
                                       3

4.  Milestone Two:  NCP Quality Support for TCP on ARPANET
  Today, there exist hosts on the internet that speak only TCP.  However, these
hosts  are  very  substantially  limited as to what they can do.  The intent of
this milestone is to define a point at which a TCP-only host connected  to  the
ARPANET  can obtain a level of service to all other hosts directly connected to
the ARPANET that it might achieve using NCP  today.    This  goal  is  for  the
ARPANET only, not the general internet.  This restriction is important, because
it  defines  the  point at which a host converting from NCP to TCP can obtain a
reasonable service to other hosts to which it previously had NCP access.

  In order to achieve this goal, there must be conversion facilities  available
so  that  the  TCP  host  can  communicate  with  NCP-only hosts, and symmetric
conversion routines must be available to permit NCP only hosts to  have  access
to  the TCP host.  The exact function required for conversion in each direction
is slightly different, since the  protocols  available  on  the  TCP  side  are
sometimes  somewhat  more  powerful,  as  in  SMTP,  and  we  are interested in
providing a better level of service for the TCP only host than we are  for  the
unconverted NCP only host.  The specific requirements for this milestone are:

  a. Telnet forwarding in both directions.  This is a machine which speaks
     both  TCP  and NCP, to which a user can log in using one protocol and
     then request an outgoing telnet connection using the other protocol.

  b. FTP staging facility.  It appears to be rather difficult to build  an
     automatic facility for linking two FTP transfers together end to end.
     The  FTP  syntax  is  not  rich  enough so that one can describe to a
     forwarder where the ultimate destination of the  transmission  is  to
     be.    Thus,  since  this  is  only  a transition mechanism, it seems
     sufficient to create an FTP  facility  which  is  operated  manually.
     First the user transfers this file to an intermediate point, and then
     he  manually  logs  in  to  this  intermediate point (or to the final
     destination  machine)  to  transfer  the   file   to   its   ultimate
     destination.

  c. Mail  forwarding.  This is a very important facility, since mail is a
     very important part of the day to day business of  the  ARPANET,  and
     because  it  will  be  a  highly  visible means by which we will make
     conversion to TCP popular.  SMTP has been specifically implemented to
     make possible the use of forwarders  to  provide  automatic  protocol
     conversion.  As originally proposed, automatic forwarding of mail was
     to  be  implemented  by causing every host on the ARPANET, whether or
     not it supported TCP, to implement SMTP by this milestone.  It is not
     clear that universal conformence can be achieved.    I  propose  that
     this  strategy  be  modified to permit an alternative in which a more
                                       4

     sophisticated forwarder will permit mail to flow from an NCP to a TCP
     host  if  the  sender  of  the  mail  manually  constructs  a special
     destination string which triggers forwarding.

     In order to achieve SMTP service, the following  sub-milestones  must
     occur.    First,  the  definition of the protocol must be stabilized.
     This  is  now  being  done.    Secondly,  mail  forwarders  must   be
     implemented and brought to a service level.

  d. The  TCP-only  hosts  must  be  identified  and  brought  to  a full,
     functional level.  Full function includes the following:

         -IP

         -ICMP

         -TCP

         -TELNET(User, Server)

         -FTP(User, Server)

         -SMTP(Sender, Receiver, Composer)

     As part of implementing this rather ambitious list of  protocols,  it
     is  important  to identify and eliminate certain popular deficiencies
     which appear in some existing  implementations.    For  example,  the
     structure  which  exists  between  the  protocol layers for reporting
     errors must be rich enough that network conditions such as  host-dead
     or  imp-dead  correctly  terminate  the  network  connection with the
     appropriate message for the user.  For another example the name table
     must be upgraded from an ARPANET only to an internet facility.

  There is a great deal of work implied by the above list.  Currently  none  of
the  forwarders,  either  TELNET,  FTP,  or  SMTP, exist except in experimental
forms, and it is not clear that these experimental forms in  fact  provide  the
basis for a service offering.  This milestone is seven months away, and it will
require prompt effort to achieve it.

  It  is  not  the  purpose  of  this  milestone  to  encourage  (or  permit) a
"preliminary" host implementation  suitable  only  for  the  relatively  benign
ARPANET  environment.    The  host  implementor should be working toward all of
these goals at once.  It is in  the  networks  that  these  milestones  can  be
distinguished.
                                       5

5.  Milestone Three:  NCP Level Service Over Internet
  This  is a somewhat vague milestone, and items which appear only on this list
have a habit of being repeatedly postponed in  task  schedules.    Nonetheless,
this  is an important goal, because it will establish the point at which we can
stop tinkering with the service we provide and proceed on to the next level  of
design.    It is important not to include too many items in this list, less the
list grow so big that we never complete its implementation.  On the  otherhand,
if  we  do  agree to include something on this list, then we must be consistent
and sincere about implementing it  in  all  the  relevant  machines.    Partial
implementation  is  not  a  useful  middle ground.  The following functions are
nominated for this category.

  a. Robustness features.  Included in this category  are  replication  of
     hardware  to  provide  an  alternative  path  in the case of a single
     component failure.  This is particularly important in the SATNET link
     to Europe.  Dual gateways may be required in other  locations,  where
     important acces nets enter the transport core.

  b. Fault  detection  and isolation.  "Dissapearing packets" are still an
     overly common aspect of internet communication.  It is important that
     every host be equipped with suitable tools  to  detect  and,  to  the
     extent  possible,  recover  from internetwork outages.  At a minimum,
     all hosts must use  the  ICMP  facilities  of  host  unreachable  and
     redirect  to recover from gateway outages or at least notify the user
     that further communication is impossible.  It is also important  that
     tools be put in place so that proper repair procedures are instituted
     properly when a portion of the internet fails.

  c. Proper  handling  of  option  fields  in  the  protocols.  Currently,
     options are most commonly processed by ignoring them.  We must decide
     which options we are really serious about and  implement  them.    An
     obvious topic for discussion is the set of options that deal with the
     source route function.  This is a good example of where we must do an
     all  or  nothing  implementation.   Isolated implementation of source
     route is demonstrably useless.

  d. Access control.  Certain mechanisms for  controlling  access  to  the
     internet  must  be  implemented as part of the interim service.  At a
     minimum, these include  login  features  in  the  TAC.    It  may  be
     necessary  to implement some further controls inside the gateway, but
     as yet no one has conceived of what those mechanisms could be.   This
     topic requires consideration.

  e. Name  servers.   The number of hosts, and thus the number of names in
                                       6

     the  internet  is  much  larger  than that of the ARPANET.  Many name
     tables are overflowing. One way to avoid this problem is by providing
     name servers to which a host  can  turn  in  order  to  translate  an
     unknown  name  into  an  internet address.  In some respects, a namer
     server is a very simple mechanism, but it is very easy to  develop  a
     name  server mechanism which is so complicated as to be unrealizable.
     Some firm decision must be made as to the  level  of  service  to  be
     provided  by  name  servers  in  the internet, and then to provide an
     implementation  strategy  whereby  name   servers   are   universally
     available.

6.  Milestone Four:  Heavy Traffic Over the Internet
  This  is  difficult  milestone  to quantify, since we do not know the rate at
which traffic will build up, nor what maximum traffic level  we  must  support.
Nonetheless,  it seems clear that the existing gateway implementations will not
support the expected load.   There  are  three  improvements  which  have  been
proposed to address this topic.  All of these depend on replacement of existing
gateways with C/70 gateways or recoding of the existing software, so that there
is additional space available.

  a. Upgrade the net interface software so that it shows more intelligence
     about  interacting with the support network.  For example, the driver
     for the ARPANET should count RFNMs, and the  driver  for  the  SATNET
     should  interact properly with the selective refusal mechanism of the
     SATNET's non blocking interface.

  b. More buffers in the gateway.

  c. Improved instrumentation in the gateway, so that it  is  possible  to
     determine where bottlenecks are.

  In  addition  to  gateway  tuning,  we need to achieve a minimum level of TCP
"good behavior".  The occurrence of Silly Window Syndrome under heavy load must
be avoided, or the net will clog up totally.   Hosts  must  provide  sufficient
buffering to obtain reasonable throughput under long-delay situations.

  Finally, we must begin to plan for substantial congestion control problems in
the  internet.    The  existing  algorithm,  which  is based on a source quench
message from the gateway to the host, has not been shown to work well.  In  the
short  run,  we  have  not identified any alternative mechanism which will work
better.  At a minimum, every host and gateway should implement  ICMP,  so  that
source  quench  messages  can  at  least  be  sent  and received.  More work is
required in this area to determine what the proper action should be.
                                       7

  Milestones  three and four are closely related, and could have been combined.
The distinction is that milestone three contains things that must be done  even
if  the  offered load is small.  Adequate performance may depend on new gateway
hardware, which may delay milestone four.    If  this  is  so,  users  will  be
interested in milestone three as a separate goal.

7.  Milestone Five:  NCP Service is Discontinued in the ARPANET
  This  milestone  has  occasionally been described as a very important one for
the internet implementors.  In fact, most of the work necessary at the internet
level to achieve this goal  will  have  been  done  as  part  of  the  previous
milestones.    There  are  essentially  two  important  subcomponents  of  this
milestone:

  a. The TCP TAC must be deployed.  This is very important, and should  be
     done  somewhat  in  advance of this actual milestone to allow for the
     following point.

  b. Facilities for testing and debugging new TCPs  must  be  conveniently
     available  on  the  ARPANET, so that hosts converting from NCP to TCP
     can verify the correct operation.

  The major effort in achieving this milestone is  the  implementation  of  the
previously  itemized  list  of protocols on every host attached to the ARPANET.
This task will require substantial effort, but this effort is provided  by  the
system  maintainers  for  the  systems  in  question.  Our responsibility is to
provide the proper support for those implementors.

  In addition to the testing and debugging facility provided above,  the  other
important requirement is informal documentation that provides help and guidance
to  implementors  beyond  the  actual protocol specification.  A number of ways
have been proposed to provide this informal help.   One  easy  strategy  is  to
distribute  a collection of TCP design documents for the TCPs that have already
been implemented.  I am currently preparing a number of reports that attempt to
gather together the insights about TCP and IP which are well understood in  the
implementation  community  but  may  not be obvious to first time implementors.
First  topics  include  strategies  for  reassembly  and  packet  resequencing,
management  of  window and acknowledgement algorithms, and proper management of
names, addresses, routes, and ports.  Anyone wishing to contribute to this work
should contact me.  A table of contents will be out soon.

  There are a large  number  of  preliminary  milestones  associated  with  the
upgrade  of  all  ARPANET  hosts  to  TCP,  such  as document distribution, and
interaction with the various host maintainers, and managers.    These  subgoals
are  not  outlined  in  this document, but are described in a separate document
recently released by Jon Postel.
                                       8

8.  Priorities
  The preceding discussion of the five service milestones has presented a rough
outline  of subtasks necessary to achieve these five goals.  A separate project
milestone document, now being prepared, lists these individual tasks in a  more
structured form, and provides dates and probabilities of success where known.

-------